Recently, a network function virtualization (NFV) working group consisting of international mainstream operators is officially set up for the purpose of promoting demands. The working group is set up to define demands on network function virtualization of the operators and related technical reports, and implement some network functions in common high performance servers, switches, and memories with reference to IT virtualization technologies. Scenarios concerned about by the working group includes a broadband network gateway (BNG), Carrier Grade Network Address Translation (CG-NAT), a router, an evolved packet core (EPC), an IP multimedia network subsystem (IMS), a radio access network (RAN), a home network, and the like.
Various types of network devices such as a server, a storage device, and a switch all can implement separation of software and hardware by using an NFV technology, and completely separate software defining a network function from a common high performance hardware server, a memory, and a network switch, to obtain a virtualized functional entity virtualized network function (VNF). A network function is implemented in a software manner by using the NFV technology, can run on common server hardware, and may be migrated, instantiated, or deployed at different positions in a network as needed, without the need of installing a new device, for example, may be deployed in a data center, a network node, or a house of a user. A software device can be completely automatically and remotely installed and managed based on common hardware. Moreover, an operator may provide a faster and better network service by implementing separation of software and hardware.
In a Long Term Evolution (LTE) network, one eNodeB may establish a connection to multiple MMEs in a mobility management entity (MME) pool. According to a function of load balance between MMEs, user equipment (UE) that newly enters the MME pool is allowed to be directed to a suitable MME in the pool according to load balance between the MMEs in the pool. To select a suitable MME, an eNodeB needs to learn a load status of the MMEs in the pool, and set weight information for the MME on the eNodeB according to an indication of the MME. For example, a new MME is added to the MME pool, and a weight value of the MME may be set to a very high value, to increase load of the MME as soon as possible. When the load reaches a set value, the MME instructs the eNodeB to reduce a weight.
In a current manner, one eNodeB is responsible for service logic configuration of only a single MME, and cannot acquire information about an entire network; therefore, service allocation is performed only for a single MME, and a requirement for load balance cannot be satisfied.